In a network environment, it is frequently desirable to share data between two or more computing devices. For example, in a client-server environment in which users have clients (e.g., computing devices) that access a centralized server, there is a need to support those users who regularly use multiple clients. In this case, it is desirable to share information on a user's state between each client that the user uses. However, state information is typically divided between the server and the client. In particular, in order to support off line use of the client, the state information to which the user will require access when the server is not available is generally stored at the client. As a result, when the user changes from one client to another, the portion of the state information that is local to the first client is not available on the second.
One solution is to maintain a copy of the state information stored on the client on the server, and use a replication mechanism to ensure that the server copy is kept in synchronization with changes that are made on each client and vice versa. For example, when a user begins using a new client, the state information on the new client is initialized using the server copy. Similarly, when the user modifies one or more data items in the state information, the server copy is synchronized with the modified state information. In this manner, the state information on multiple clients can remain synchronized using the server copy.
An important part of each user's state information is the security credentials, such as cryptographic key(s), certificate(s), password(s), and/or the like. Typically, some security credentials are considered extremely sensitive and should be closely protected. For example, a private key that is used to sign the user's email is generally considered a sensitive key, since its compromise would enable another to impersonate the user. Therefore, such security credential(s) frequently are encrypted, e.g., using a pass phrase known only to the user, when replicated using the server. This substantially reduces the likelihood that the security credential(s) can be successfully stolen and/or modified by another party, such as a server administrator.
A goal in designing a protocol for the replication is to minimize an amount of data that is exchanged between the client and server. To this extent, it is desirable that a replication protocol only require the transmission of those security credential(s) that changed since the last replication. However, if multiple security credentials are encrypted as a single blob, individual credentials cannot be exchanged between the server and client (only the entire blob may be exchanged). On the other hand, when each security credential is encrypted and stored individually, another party with access to the server may remove a security credential or replace it with an earlier instance without detection. Since some security credentials may represent statements of trust (or distrust), this is an undesirable vulnerability.
In view of the foregoing, there exists a need in the art to overcome one or more of the deficiencies indicated herein.